Fix union equivalence schema rewrite with stale constants - #23375
Conversation
github-actions
Bot
added
physical-expr
There was a problem hiding this comment.
@xudong963
Thanks for the targeted fix.
The unit test covers the stale metadata case well, and I have one small follow-up suggestion that is not blocking.
| } | ||
|
|
||
| #[test] | ||
| fn test_union_drops_unrepresentable_constant_value_after_schema_rewrite() -> Result<()> |
There was a problem hiding this comment.
Nice targeted test for the stale metadata state. As a follow-up, it may be worth adding a higher-level regression test that builds the filter/projection/union plan shape from the original issue and checks that UnionExec::try_new or physical planning succeeds. That would help protect the full path that produced the stale constant, not just the calculate_union boundary.
There was a problem hiding this comment.
Thanks, that makes sense. The current test intentionally targets the exact stale-metadata boundary in calculate_union. I agree a higher-level regression would be useful, especially if we can capture the original filter/projection/union shape reliably. Since the reduced issue does not include a concrete SQL repro and the normal projection path should drop removed-column constants, I’ll keep this PR focused and consider adding a UnionExec::try_new/planner-level regression as a follow-up.
2 participants
Which issue does this PR close?
Rationale for this change
UnionExec::try_newcan panic while computing equivalence properties if stale constant metadata is carried across a projection and then rewritten to the union output schema.In the observed shape, a filter such as
ticker = 'ESU6'can leave a uniform string constant in equivalence properties. After a parent projection dropsticker, union property schema rewriting can see the remaining column slot as a timestamp column and attempt to cast'ESU6'toTimestamp, which fails during planning.Equivalence constants are optimizer metadata, so an unrepresentable constant after schema rewrite should be discarded rather than failing query planning.
What changes are included in this PR?
EquivalenceProperties::with_new_schemaif its value cannot be cast to the rewritten expression type.UnionExec::compute_propertieserrors fromUnionExec::try_newinstead of unwrapping.Are these changes tested?
Yes:
Are there any user-facing changes?
No API change. This prevents a planner panic for affected
UNION ALL+ filter + projection query shapes.